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AUSTRALIAN UNIX USERS GROUP NEWSLETTER 



In This Issue 


This issue tidies up some loose ends left in the "to be published" file. The 
Sydney UNIX network has at last been summarised by Piers and Bob from Basser 
and the Berkeley network introduction is interesting. 


Last AUUG Meeting 


The last AUUG meeting went well with about fifty people attending. A list of 
attendees and an agenda appear in this issue. 

I spoke about the "birds of a feather" meetings at the Austin conference. I 
have not had time to summarise what I said but plan to for the last issue of 
this volume, should no better summary appear before then. High School UNIX 
appears to be an Interesting topic and I asked David Woodrow, of St. Peter's 
Lutheran College, to send me a write up of the system that Darryl Whimp spoke 
of during the conference. Ross Nealon told us how PE UNIX was faring at 
Wollongong and I hope to see some words from him too. 

Dave Horsfall and Chris Rowles have set the example by summarising their talks 
on "A simple bad-block utility" and "Using the Sanders printer". 


-Formal AUUG 


I put forward two proposals to formalise the AUUG at the Queensland 
conference, and what a "bun-fight" ensued. The proposals were that the 
Australian UNIX users form a DECUS SIG (you need five bodies to start it up) 
and that also we should elect a number of formal AUUG office bearers as the 
publicly visible representatives of the group. 

I won t go into the discussion that ’followed but we elected a few people with 
the following jobs. 

David Horsfall — Chairman Computing Services Unit 

Uni of N.S.W. 

P.0. Box 1 
Kensington 2033 
AUSTRALIA 

Chris Maltby - Secretary/Treasurer Basser Dept of Computer Science 

Madsen Building. F09 

1 Uni of Sydney 

N.S.W. 2006 ' 

AUSTRALIA ’ 
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Bob Kummerfeld - Editor in chief Basser "Dept of Computer Science 

Madsen Building. E09 
Uni of Sydney 
N.S.W. 2006 

. AUSTRALIA 

Chris Rowles - Editor Dept of Chemical Engineering 

Uni of Sydney 
N.S.W. 2006 
AUSTRALIA 

Ron Baxter — Committee member Elected in his absence 

Please note that the primary role of the committee is, initially anyway, to 
look into the benefits and draw—backs of becoming formal, either under the 
auspices of DECUS or on our own. 


New AUUGN Editors and Subscription Costs 


Bob Kymmerfeld and Chris Rowles, the new AUUGN editors, regret to inform you 
that the subscription cost for AUUGN volume four will rise as from the 28th of 
September 1981. The new price is (Australian)$24-00 and will apply to all 
subscriptions received after that date. 

Reasons for the price rise are obvious. The last issue of AUUGN, volume three 
number four, cost $2-73/issue to produce and mail. This is even with the very 
cheap production I am able to obtain, through the School of Electrical 
Engineering and Computer Science, and the large pool of volunteer labour I 
have to draw on. 

All you people who subscribed early have saved yourselves $12-00. Send 
subscription letters and monies to Bob at the address above. 


Well it's better than Key's chicken 



Peter Ivanov 

Dept, of Computer Science 
Electrical Enginee3.*ing 
University of N.S.W. 

PO Box 1 
Kensington 2033 
AUSTRALIA 

(02) 662-3781 
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3:30 

***** 

Registration & Coffee ***** 

10:00 

Peter 

>>>>> 

Ivanov 

U.S, UNIX Meeting odds and ends <<<<< 

10:25 

Darryl Whimp 

>>>>> High school UNIX <<<<< 

10:45 

Ross Nealon 

>>>>> What^s on at Wollongong <<<<< 

11:10 

Dave Horsfall 

>>>>> A simple bad-block utility <<<<< 

11:35 

Chris 

Rowles 

Using SANDERS printers under UNIX <<<<< 

12:00 

»>» 

Formalisation of AAUG <<<<< 

12:30 

***** 

LUNCH & Sticky-Beaking ***** 

14:00 

Kevin 

Hill 

Modifications to V7 <<<<< 

14:25 

George Gerrity 
>>>>> ????? <<<<< 

14:50 

»»> 

Formalisation of AUUG {again!} 

& selection of new editor 

6 selection of next meeting site <<<<< 

15:30 

***** 

Afternoon Tea ***** 


16:00 Whatever takes your fancy 
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A Proposal 
for a 

Simple Bad Block Utility 

Dave Horsfall 
Computing Services Unit 
University of NSW 

(dave:unswcsu) 


1. INTRODUCTION 

This is a proposal for a utility to "flaw" out bad blocks on a file system. It 
was prompted by having to write off an RP03 disk pack which had suffered from a 
minor head crash, resulting in a small scratch across the surface. Given the 
track density of the pack, it was impractical to logically remove the affected 
cylinders by redefining the file systems on it. Similarly, any genuine bad 
block support utilizing the sector header information would be uneconomical 
given the amount of work required to implement it and the benefits gained. It 
should be mentioned too that it was only slightly more expensive to buy a new 
pack than to refurbish the old. Some intermediate solution would therefore seem 
to be. attractive. 

The proposed utility FLAW offers the following advantages: 

* No modifications to operating system, 

* No reserved filenames or I-numbers, 

* Usable on all disk drives (even floppies!), 

* Flexible enough fcr most purposes. 

It does have the drawback that if the bad block happens to be the super block, 
inode etc then nothing can be done about it. However, since these form but a 
small fraction of the file system this is not expected to be a problem. The 
accent is on simplicity, not omnipotence. 

2. METHOD 

The method Is to raake the bad blocks unavailable to the file system by allocat— 
ing them to a known inode. The I— number of this inode is kept in the super 
block. Note that there Is no pathname, and there is nothing "special" about the 
i-number (unlike V7 UNIX). Programs such as DTP and CPIO are therefore unaf¬ 
fected by it, and programs like DUMP can automatically ignore that inode. Of 
course, image copies will fail. Programs such as ICHECK , DCHECK and NCHECK will 
need to be modified, since these blocks will show up as "missing" etc. 

The superblock entry Is Initially zero, implying no bad block file present. 
When a bad block is discovered (by reading the error log, or perhaps exercising 
the file system), the file system is unmounted and the FLAW utility run to allo¬ 
cate an inode (if required) and chain the specified blocks into the bad file. 
FLAW will need to check to see that the blocks are in the free list, as It is 
deemed undesirable to deallocate files automatically. 



Of course, when the pack is reformatted all information is lost, and when MKFS 
initializes the file system the super block entry is cleared automatically. 
Should one wish to reinitialise the file system without reformatting it then 
MKFS can be modified to accept a list of bad block numbers. 


3. SPECIFICATIONS 

FLAW would need to have the following capabilities: 

* Enter a block into the bad block-file, 

* Assign the bad block inode if necessary, 

* Display bad block numbers, 

* Only accept those blocks in the free list, 

* Check all blocks on the file system, and possibly flaw them, 

* Check individual blocks for possible flaws. 

Future capabilities can be added later. 


4. CONCLUSION 

The solution offered here is simple enough to be Implemented almost overnight. 
Its drawbacks of not handling all situations are outweighed by its simplicity 
and elegance. The concept of the bad block file fits in neatly with the UNIX 
file system, and no reserved filenames or inodes are used. 
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UNIX AND THE SANDER'S MEDIA 12 TYPOGRAPHIC PRINTER 

THE PRINTER : 

The Sander's Media 12 is a dot martix multipass printer. It produces 
letter quality printer output. The printer is microprocessor controlled 
(based on the Zilog Z-80) and has software generated character sets. 
There are currently over 4G character sets commercially available. 
Special purpose character sets can be purchased at roughly double the 
price for the stock set. These fonts are held in Texas Instruments' 

TMS 2716 (tripple voltage supply) ROMs. Font modifications or new font 
sets could be made by the user by simply programming a set of ROMs. 
Physically the Sanders is built up of four printed circuit boards. One 
contains the printer control program, the Z-80, its communication inter¬ 
face and up to four fonts. A second card is available as a font expan¬ 
sion card. This allows an additional twelve fonts to be loaded. A 
third card controls the vertical paper motion and the print head 
mechanism in horizontal motion. Control allows horizontal resolution 
of 1/1000th inch ana vertical motions of l/243th inch. The last board 
controls the pin firing mechanism in the print head itself. 

A second model has recently arrived on the market. In this model the 
print head is controlled by the user. It operates in a similar manner 
to an electrostatic plotter, in that the user must supply the raster 
information necessary to produce the printing. Very little is known 
about this model, although it should prove to be a better buy in the 
long run. All further discussion relates to the Media 12/7 printer 
with ROM loaded font sets. 


* 
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THE SOFTWARE REPERTIQRE : 

The Sanders operates as an intelligent word processing unit. It has its 
own command language to control the formatting and printing of letter 
quality documents. The command set consists of the following operations. 

Font manipulation : select font, assign logical font. 

Print head manipulation : horizontal spacing (left and right), 
vertical motion (up/down), horizontal and vertical tabbing, 
indentation from left margin, select leading (vertical line 
spacing), set/clear tab stops. 

Print format : no adjust, centre text, left justify text, 
right justify text, block justification (with inter-word 
and/or inter-letter justification)i force printing of current 
line buffer, select repeat of a character string, insert 
white space to leave the next string right justified. 

.. Page format control : length, left margin, width (ie right 
margin), top margin and bottom margin, select bold on/off, 
select underlining on/off. 

Miscellaneous options : block mode, printer, reset ribbon 
usage command, select draft mode, page eject, initialise 
printer. 

The Media 12/7 performs many text processing functions as a by-product 
of its normal operation. It determines the’line length in terms of the 
number of printable characters that will fill the current line. Lines 
larger than this are wrapped around to the next line automatically, with 
the text broken at the nearest white space prior to the line overflow. 
Thus the first part of the broken line is justified (if required) and 
printed, while the remainder of the line passes to the front of the next 
line. Lines terminated by a carriage return cause the justification to 
be ignored for such a line. Force print causes the justification to be 
applied (with some disasterous results). Single words longer than the 
current line length lead to unpredictable results. 
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THE COMMAND LANGUAGE : 

The command language takes the form of escape sequences intermixed with 
the output text. The arguments of the escape sequence is a variable 
size numeric count to set the desired option. 


eg 


<esc> 0 nnn 
<esc> 1 nnn 
<esc> u n 
<esc> b n 
<esc> a n 
and so on 


force vertical motion nnn/1000 in 
force horizontal motion nnn/1000 in 
toggle underline n/1000 in 
set bolding offset n/1000 in 
select font n 


NOTE that the number of the arguments is dependent upon the command and 
that n is expressed as a 2‘s complement binary number (each digit being 
6 bits long (0 to 5) and bit 7 clear, bit 6 set). This makes hand cal¬ 
culation of the arguments inconvenient, but gives an ASCM encoded binary 
value that can be handled by most serial line interfaces. 

This command set is very powerful. It does everything that you could 
desire, but it has some very nasty operational'restrictions. These 
relate to horizontal motions. There is a strictly enforced limit of 
20 horizontal spacing (non-printing) commands per line. There are also 
restrictions on left motion, limiting it to the width of the last 
printed character unless a vertical motion immediately proceeds the 
command. 


The vertical motion provides a mechanism by which both restrictions can 
be averted. A vertical motion forces the current line buffer to be 
printed and resets the horizontal motion counts. Hence a vertical 
motion of zero length can be used to leave the print head in the next 
print position following the last character printed, without needing 
to calculate where it is in the output page. 

UNIX SOFTWARE INTERFACE : 

\ 

A UNIX filter has been written to drive the Sanders Printer. It 
validates the basic Sanders commands, it initialises the printer to a 
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known state and it tries to optimise the command strings by concentrating 
similar command strings into a single command (eg many horizontal motion 
commands produce a single command to effect the motion). The filter also 
accepts some psuedo-commands and interprets them. Notable among these 
are the revert to previous font fine spacing commands, select paper size 
format commands. 

In its simplest form the filter takes input with imbeded Sanders commands 
and passes them directly to the printer. Thus test in the form of 
extremely long lines (ie paragraph length) uses the word wrap feature to 
produce very acceptable justified output. A simple process to calculate 
the numeric arguments for the Sanders commands, and to strip out new 
line and carriage returns, does produce very acceptable results. 

A driving table for "NROFF 11 has also been developed. Although this is 
not completely correct it does produce very nice outputs from both TBL 
and NEQN as well. NROFF was modified to handle this hardware under¬ 
lining and bolding commands by placing Sanders commands into the output 
stream rather than simulate them. NROFF also produces pseudo fine space 
commands (ie -e option) that are interpreted by the filter. Hence NROFF 
justifies the text, and the Sanders filter allows the printer to use 
its own internal operations to get the job looking really nice. 

OUTPUT QUALITY : 

The quality of the output is good.. It is very dependent upon the 
mechanical adjustment of the plotter spacing, the overall cleanliness of 
the printer and the quality of the paper used. Given a little care with 
all three above, the output is very presentable. 

The main weakness of the device is the print head itself. The firing 
pins can shear off the driving relays. They can also stick if the head 
is dirty or worn, leaving either one faint row of dots, or a score mark 
in the output. The print head costs $600 (Australian) to replace. It 
is not covered in the annual maintenance agreement, but is in the two 
yearly agreement. This is a strange policy of the Australian agents, so 
be careful if you have a maintenance contract. 

* 
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The Sydney UNIX Network 

R.J. Kummerfeld and P.R. Lauder* 


A computer network has recently been established within and between the campuses of the 
University of Sydney and the University of New South Wales. The network provides a virtual circuit 
facility for remote terminals and a fiie/mail transfer, facility. The machines participating in this net¬ 
work ail run the Unix operating system. The network software evolved out of a desire to allow the 
system maintained and developers to co-operate more closely. 

Keywords: Communication, Networks, PDP-11, UNIX. 

CR Categories: 3.81,4.35 


1. INTRODUCTION 

The Sydney Unix Network is a network of com¬ 
puters within the Universities of Sydney and New South 
Wales, that operate under the Unix Timesharing System 
(Thompson and Ritchie, 1974). The development of the 
network began in 1978 with the installation of a leased 
line connecting a PDP11/4Q computer in the Basser Depart¬ 
ment of Computer Science at the University of Sydney 
(known as “basser40”) and a PDP11/70 at the Australian 
Graduate School of Management on the University of 
New South Wales campus (known as "agsm”). This con¬ 
nection was used initially simply for access to the AGSM 
machine from a terminal connected to the Basser 11/40. 
Subsequently within each campus a number of other 
links were established and used in a similar way, i.e., a 
terminal on one machine could be used to login to a remote 
machine. Users wishing to login to a remote machine- 
would invoke a special program that copied characters 
between their terminal and the outgoing link. .At the 
remote machine the incoming iink appeared as a normal 
terminal connection. 

~~ The limitations of this initial system were: (!) only 
one user could use the link at a time even though the 
available bandwidth would satisfy many users; and (2) the 
line was directional. This may be explained as follows: 
each computer running under Unix associates a simple 
login program with each incoming line. This program 
listens-for activity on the line and Lhen normally engages 
in a login dialogue with a remote human user. If a line 
connecting two computers is regarded as an incoming line 
by both, then the two login programs may engage in an 
endless and fruitless dialogue. Worse, if a connection is 
established by one of the login programs the other may 
interfere with the subsequent activity on the line. The 
standard solution is to allow only one machine to treat 
the link as incoming and hence constrain all new activity 
to be initiated by the other machine. 

In early 1979, wider issues of network development 
began to be considered. These included file and mail 
transfer systems and virtual circuit facilities. Conventional 
ways of providing these services involve building a net¬ 
work of node computers connected together by reason¬ 
ably fast lines and with host machines" connected to the 


“Copyright ©1981, Australian Computer Society Inc. 

General permission to republish, but not for profit, all or part of 
this material is granted; provided that ACJ's copyright notice is 
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network node computers. This solution was not seriously 
considered since in many cases the cost of a node mach¬ 
ine would be comparable with the cost of the host it was 
to handle. Instead a host supported network system was 
developed that used no specialised network node com¬ 
puters and utilized the fixed and leased communication 
lines that were previously used as simple terminal 
connections. 

2. PROTOCOLS 

The protocols used in the networks do not, at pre¬ 
sent, conform to a strict layering as in other more con¬ 
ventional networks. For example, the lowest level of 
software protocol used over the physical communication 
lines is not strictly necessary far Lhe higher levels, although 
it is used for all present links. This will be made clear in 
the description of the higher levels of protocol.. 

2.1 Physical Link Layer 

The first “layer” of network protocol consists of 
the physical lines. These are either fixed lines running 
between machines in the same building or on the same 
campus or leased from Telecom. The interface to each 
machine conforms with the R5232 standard. The line 
speeds range from 1200 baud for the leased lines between 
campuses to 9600 baud for the lines between machines in 
the same building. The current topology of the network 
(February 1981) is shown in Figure 1. 

2.2 Multiplexing Layer 

The second layer Is the lowest level of software 
protocol. It involves a simple multiplexing scheme that ) 

allows one physical line to appear to the operating system 
as several virtual lines. This scheme was in fact imple¬ 
mented very early in the network development as a solut¬ 
ion to the problems that arose with the original single 
user, directional terminal connections. The multiplexing 
protocol allowed the lines between machines to be rep¬ 
licated'by software. Thus, more than one user could be 
using a physical line at the same time and several virtual 
lines could be designated as “to” a remote machine and 
several as “from” the same machine. 

The multiplexing line driver and protocol are known 
simply as ”mx”. There is very little in the way of error 
control. However, flow control is provided. 

The mx protocol multiplexes “ports” onto real 
lines and simply separates data for each porL on the line. 
Each block of data has a four byte header: 


*The authors are with the Basser Department of Computer Science, University of Sydney, Sydney, NSW, 2006. Manuscript received 3 March 
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Figure 1. Network topology 

SOri (ASCII start of header} 
port-identifier 
data-byte-count 
complement of data-byte-count 

This header is easily recognised and checked for 
consistency. The length of the data block that follows 
the header is usually limited to 40 bytes. Flow control is 
implemented by sending blocks without any data, the 
first byte count zero and the second byte count repre¬ 
senting the number of data bytes that may be received. 
The sender must not send more than the specified number 
of data, bytes before waiting for another flow control 
block. A simple timeout mechanism is used to recover 
from lost flow control blocks. 

2.3 Transport Layer 

The next network protocol layer may either be a 
virtual circuit facility or file transfer. The virtual circuit- 
scheme is simple but effective and grew out of the original 
machine-machine connections that allowed a user to 
connect his terminal “through" his local machine to a 
remote machine. (See Figure 2}. 

The program now used to make the connection to 
the remote machine is called con (there have been other 
similar programs designed for special situations). This 
program takes as argument the name of the remote mach¬ 
ine and from this determines the correct outgoing link to 
use. The program then performs a system call that would 
instruct the line driver to "connect” the terminal and the 
outgoing line. Characters are transferred from one line to 
the other very efficiently. The outgoing link may in fact 
be a multiplexed link created by “mx”, along with several 
others, from a single physical line. This is hidden from 
the user and the con program. 

In order to allow a user to connect to a remote 

The Australian Computer journal, Vol. 73, No. 2, May 7987 


machine that is further away, i.e., that involves more than 
one intermediate machine, the con program carries out 
the extra function of routing. As part of the file transfer 
system, a network topology file is maintained. The details 
of this file will be described later. However, it does con¬ 
tain a list of all the network hosts and machines they are 
directly connected to. For example, from Figure T'the 
topology file (called "netstate 1 ') would contain an entry 
for the host “basser40” as follows: 

basser40 agsm 

•* basservax 
-*• chemeng 

and the entry for. "basservax’’ is: 

basservax -*• basser40 
•* eleevax 

The con program consults this file before making a 
connection and determines the route of such a connection. 
For example, if a user at a terminal that is directly con¬ 
nected to the "basser40" types “con eleevax”, then the 
con program consults the “netstate” file and discovers 
that the route from basser40 to eleevax is via basservax. 
it then sets up a connection to basservax and sends a 
special message to the login process at basservax that 
indicates that a connection is required to eleevax. The 
login process at basservax then in turn starts a con pro¬ 
gram with "eleevax” as argument and the process repeats. 
When the login process at eleevax receives the special 
message (now generated by a con program on the basser¬ 
vax) it ignores it and the login proceeds as usual. 

When the user has finished his session and logged 
off the remote machine, he types a special escape char¬ 
acter that is interpreted by the con program running at 
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Local Host 
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con program Login program 

Figure 2. Terminal-local host-remote host 


the local machine (A in Figure 3). This machine will in 
turn pass an escape character on to the next machine in 
the route (B in Figure 3) and so on until it reaches the 
remote machine. The con programs running at the remote 
and intermediate machines terminate, returning control 
to the login process in each case. The con program at 
the local machine also terminates and the users command 
interpreter regains control. 

This scheme is very simple and has proved to bs an 
effective solution. Connections are made from one side 
of the network to the other without problem. 

3. FI LE TRANSFER LAYERS 

The other major part of the network is the file 
transfer system. It is implemented in three levels that 
may or may not be used above the "mx" level. It is poss¬ 
ible for it to operate on dedicated lines between mach¬ 
ines but in practice it uses one port of an mx controlled 
line. 

The top level is the user interface layer, the second 
level, implements an end-to-end protocol and maintains 

Host A 


the network topology file, while the lowest level pro¬ 
vides an error-free path between directly connected nodes. 
Figure 4 is a diagram of the protocol levels of the system. 

3.1 User Level 

At the user interface level, files, electronic mail or 
printer output may be transferred by a user from his 
home machine to any other on the net by using a 
single command. Network addresses are of the form 
“username:hostname'* where “username” is a valid login 
name on the remote host whose network name is 
"hostname”. ThL form of address is recognised by the 
mail program and the mail item is then handled by the 
“net” layer of the protocol. 

The file transfer system is implemented with two. 
user commands. These are “netsend” to send one or more 
files to a remote host, and “netget” to retrieve a file .at 
a user’s local host which has arrived as the resutt of a 
netsend on a remote machine. The netsend command has 
at least a usernamerhostname argument and may have one 
or more file name arguments specifying the files to be 

Host B ' Host C 
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figure 4. End to End Level. 


sent. If no file name is specified, the standard input file 
is used. This is usually the users' terminal but may be a 
"pipe'’ from another program. The netget command 
takes zero or more option and filename arguments; when 
used without arguments it retrieves files that have been 
sent from other users or hosts and placed in a holding 
directory (or "spool"). It is important to note that netget 
does not allow a user to reach out from his local machine 
to some remote host and copy files. It is one of the major 
design decisions of this network file transfer system that 
this facility not be provided, the main reasons being sec¬ 
urity and the desire for simplicity. If the facility were 
available, a system of network wide user validation would 
have to be implemented. Since almost ail the machines on 
the net are independently managed, and some .have large 
numbers of potentially hostile student users, it was felt 
that such a scheme would be difficult to implement in a 
secure way. With the current system a user wishing to get 
a file from a remote machine would invariably have a 
valid user-name on the remote machine and so would be 
able to use con to the remote machine and "netsend" 
the file to his local machine. 

The other service currently available at this level is 
a remote printing facility. A user may use the command 
"netprint remote-host-name file-name . . . ” to print a file 
on a printer attached to a remote host. The file is sent 
using the. normal file transfer system but is passed Lo 
the line printer handling program (or "daemon”) when 
it arrives at the remote host. 

Also available to the user are two ancillary pro¬ 
grams, "netq” and "netstate”. The "netq” program gives 


information about files waiting ro be sent to directly 
connected hosts. The origin, destination, size and position 
in the relevant queue are given. The “netstate’ 1 program 
lists the network topology file in a readable form. 

3.2 End-to-End Level 

The next lower level, implemented by the program 
"net" (sec Figure 4), accepts files for transmission, deter¬ 
mines the next node in the route to the destination host 
and saves the file together with an end-to-end protocol 
header in a director/ set aside for the next host in the 
route. 

The end-to-end protocol header contains the follow¬ 
ing information: 

destination host name 
destination user name 
origin host name 
origin user name 
action 
file name 
action parameters 
statistics 

When, a file is received by the lower"netd" level it 
is passed to the net program for processing. If it is destined 
for the local machine it is placed in a directory to be 
retrieved eventually by a user via the netget program. 
Also a message is sent (by system mail) to the user notify¬ 
ing him of the arrival of the file. A time limit is placed on 
the files in the reception directory after which they are 
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removed. The user is warned of this time limit in the 
arrival notification message. If a received file is enroute 
to another host, it is placed in the appropriate directory 
and the “netd" level program will send it on to the next 
node in the route. The next node is calculated by the 
"net'’ program from information found in the “netstate” 
file. This is a “staging" system that involves complete 
reception of a file at an intermediate machine before 
sending it on to the next machine in the route. This has 
the disadvantage of requiring enough file storage at inter¬ 
mediate nodes to contain all the in-transit files, but this 
has not proved to be a problem. The benefit of the scheme 
is that it greatly simplifies the end-to-end protocol and 
allows routing decisions to be distributed across the 
network. 

The net program also maintains the network topology 
file called “netstate” which contains an entry for each 
host. Each entry includes the time that the named host 
was last active and the transmission rate achieved. Follow¬ 
ing this is a list of hosts that are directly connected to the 
named host. Example entries have been given earlier. 
Each time the lower level “netd" program is started it 
signals “net” to send a message to all directly connected 
hosts indicating that the local host is now active. The 
directly connected hosts propagate this “host-up” message 
through the rest of the network and also send a copy of 
their “netstate” file back to the new host. When a dir¬ 
ectly connected host does not respond to some message 
and is deemed to be down, the netstate file is modified 
to indicate the new state. Thus, the network topology 
information is maintained by the “net" program to reflect 
the current state of the network. 

3.3 Node-to-Node Level 

Below'the “net” program level the node-node file 
transfers are handled by a program known as “netd" or 
network daemon. In each machine there is a copy of this 
program executing for each directly connected host. For 
example, in the basservax host there are two invocations 
of netd, one for the basser4G and one for the eleevax 
host. In the eleevax and basser40 there would be a netd 
program running to handle the link to basservax. The netd 
programs at each end of a given link co-operate to trans¬ 
fer files from one node to the other. 

Netd uses a half-duplex, multi-buffered, positive 
acknowledgement data transfer protocol. Before each 
file transfer the netd programs negotiate the direction; 
file transfer then proceeds with short data blocks enclosed 
in a protocol envelope. 

. . The header consists of the following 8 bit bytes: 

SOH (ASCil start of header character) 
sequence number 
size of block 

complement of size of block 
while the trailer is: 

longditudinal parity check . 

sum check 

The sequence number is used to provide the multi- 
buffered flow control. Each packet must be responded to 
with a two byte reply consisting of an ASCII ACK or NAK 
character and the relevant sequence number. Errors cause 
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the retransmission of all un-ACKnowledged packets. 
Catastrophic error conditions cause a negotiation for re¬ 
start of the file transmission. The error check characters 
were chosen as the simplest to compute and yet have a 
reasonable chance of detecting errors. 

The netd program executing on behalf of a partic¬ 
ular host-host link scans a designated file directory for files 
to be sent. The files arc placed in the directory by the 
"net” program. , 

4. IMPLEMENTATION EXPERIENCE 

The system was implemented by one of the authors 
(PRDL) over a period of two months with a total time 
spent on the project of six man weeks. It has now been 
operating for six months and has fulfilled the original 
aims of allowing closer co-operation between system 
maintained and developers. Other, non-system program¬ 
mer users are now beginning to use the system for such 
things as preparation of teaching materials. 

The programs arc all written in the programming 
language C (Kcrnighan and Ritchie, 1978) except for 
the “netsend” and “netprint” commands which are com¬ 
mand interpreter procedures that invoke the “net” pro¬ 
gram with appropriate parameters. The number of lines of 
C code is just under 7000. The size of the binary code of 
“net” is approximately 22,000 bytes and of “netd” is 
19,000 bytes. The system has been implemented on a 
number of different machines and versions of Unix. It is 
currently operational on Vax 11/7S0, PDP11/40, PDP11/ 
34, PDP11/60 and PDP11/70 machines under Unix vers¬ 
ions 6 and 7. 

5. FURTHER WORK 

While the file/mail transfer system is operational 
only on systems running the Unix operating system (but 
on a variety of different machines), there are a number 
of non-Unix machines that can be reached via the con 
program. These include CDC Cyber machines at both 
Sydney and NSW University computing facilities. Recently 
a link has been established between the basser40 and a 
CSIRONET nude machine located on the Sydney Uni¬ 
versity campus. This link uses the “mx" multiplex pro¬ 
tocol and allows several users simultaneous access to 
CSIRONET hosts. It also allows users connected to the. 
CSIRONET to connect to the Sydney Unix Net. 

The network will undoubtedly grow with more 
Unix hosts (at least three more are expected at Sydney 
University in 1981). The main enhancements to the net¬ 
work software will involve gateways into other networks 
such as CSIRONET and experiments with trans-network 
file and mail transfer. This will entail modifying or adding 
to the existing programs and protocol layers. For example, 
a trans-network mail system that uses the facilities of 
CSIRONET and the American Telenet is planned. This 
will allow'mail transfer between local users and colleagues 
in America. 

6. CONCLUSIONS 

The Sydney Unix Network is a simple but effective 
system that provides a virtual circuit facility, a terminal 
connection system and a file/mail transfer system. The 
simplicity of the design meant that a comparatively small 
amount of effort was required to implement the system 
and it has proved to be very easy to maintain. At the 
user level it provides an effective means of co-operation 
between users at widely separated sites. 
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ABSTRACT 

This document describes the use of a network between a number of 
UNlxj machines on the Berkeley campus. This network can execute commands 
on other machines, including file transfers, sending and receiving mail, remote 
printing, and shell-scripts. 

The network operates in a batch-request mode. Network requests are 
queued up at the source and sent in shortest-first order to the destination 
machine. To do this, the requests are forwarded through a network of inter¬ 
connected machines until they arrive at their destination where they are exe¬ 
cuted. The time this requires depends on system load, inter-machine transfer 
speed, and quantity of data being sent. 

The network enforces normal UNIX security and demands a remote 
account with a password for most commands. Information can be returned to 
the user in files, for later processing, or on the terminal for immediate viewing. 


Introduction 

A network between a number of UNIX machines on the Berkeley campus has been imple¬ 
mented. This document is a brief introduction to the use of this network. Information which 
is specific to the local network has been gathered into Appendix A. The new user should read 
both this introduction and Appendix A in order to learn to use the network effectively. 

This document is subdivided into the following sections: 


tUNIX is a Trademark of Bell Laboratories. 
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Use of the Network • 

1) Copying Files over the Network 

2) Listing Requests in the Network Queue 

3) Removing Requests from the Network Queue 

4) Sending Mail over the Network 

5) Reading Mail over the Network , 

6) Using the Lineprinter over the Network 

7) Net Prototype Command 
Setting Defaults 

How to Specify Remote Passwords 
Appendix A: The Network at Berkeley 
Appendix B: Getting Started — An Example 

This manual is written in terms of three mythical machines, named X, Y, and Z. Specific 
names at Berkeley are in Appendix A, along with more local information. 

Use of the Network 

The network provides facilities for issuing a command on one machine (the local 
machine) which is to be executed on another (the remote machine). Network commands are 
available to transfer files from one machine to another, to send mail to a user on a remote 
machine, to retrieve one’s mail from a remote account, or to print a file on a remote line- 
printer. These commands are described below, as is the more genera! net command which 
allows users to specify the name of some command or shell script to be executed on a remote 
machine. Network requests are queued on the local machine and sent to the remote machine, 
forwarded through intermediate machines if necessary. 

Most of the network commands require that you have an account on the remote machine. 
If a remote account is not needed for a particular command, it will be noted in the following 
discussion. The first example introduces procedures and responses which are applicable to all 
network commands. 


X. Copying Files over the Network 

Suppose that you have accounts on both the X and Y machines and that you are presently 
logged into the X machine. If you want to copy a file named ‘filer from your current directory 
on machine X to machine Y (the remote machine), use the command: 

% netcp filel Y:filel 

The net will make a copy of ‘filel’ in your login directory on the Y machine. (The ‘Y:’ will not 
be part of the filename on the Y machine.) In order to verify your permission to write into the 
^ Y account, the netcp command will prompt you with: 

Name (Y:your-name): 

You should respond with your login name on the Y machine, followed by a carriage-return. If 
you have the same login name on both machines, jus', type a carriage-return. Next a password 
will be requested: 

Password (Y:remote-name): 

Now type in your password followed by a carriage-return (you must type it even if your pass¬ 
words are the same on both machines). The netcp command will make a copy of your ‘filel’ in 
a queue destined for the Y machine, and will then return you to the shell. 

Likewise if you wanted to transfer a file named ‘scan.p’ from Y to X, 

% netcp Y:scan.p scan.p 




AUUGN 


19 



-3- 


would place that file in your current directory on X. 

The network will “write” you when it has executed your request (if you are still logged 
in), or will “mail” you a message (if you are not). You may use the — n option (described 
feter) to disallow the interruption and thus force mail to be sent. A typical message might look 
Ske this: 

Message from Y:your-name at time ... ’ 

(command: netcp filel Y:filel, R: 0, sent April 1 18:03, took 10 min 3 sec) 


Hie message includes the current time, the time you sent the command on machine X, and the 
exit code of the command (zero normally means success). 

The network response will tell you if it was unable to execute the remote command suc¬ 
cessfully by returning an error message some time later. If, for example, you type the wrong 
password, you will get the response 

Message from Y:your-name at time ... | 

(command: netcp filel Y:filel, sent April 1 18:03, took 10 min 3 sec) j 

Error: bad login/password your-name ' 


The netcp command is actually a generalization of the UNIX cp command, similar to uucpt. 
Its syntax is: 


netcp [—1 login] [—p password] [—n] [—q] [—f] fromfile tofile 


where frorrfile and tofile can be local or remote files. A filename which is not a full pathname is 
either from the current directory on the local machine or your login directory on the remote 
machine. The —1 and — p options may be used to specify your remote login name and pass¬ 
word on the command line. If the password contains shell meta-characters, it must be in 
quotes. (These options are useful in shell scripts, but be sure to make the shell script readable 
only by yourself if you’ve got passwords in it!) The —n option forces any responses from the 
remote machine to be mailed rather than written to you. The —f option forces prompting for a 
remote user name and password, even if they are set by other options or are in the “.netrc” file 
{see “Setting Defaults” below). Finally, the —q option prevents any confirmation messages 
from being sent back to you, if there were no errors, the exit code of the command is zero, and 
the command had no output. 


Transferred files may or may not have the correct file protection mode; use the chmod (I) 
command to reset it. When files are to be brought from a remote machine, they are created 
zero-length at the time the command is issued; when they arrive, they, assume their true length. 
Unlike cp, netcp does not allow the tofile to be simplified to a directory, if the files have the 
same name. 


Examples: 


% netcp 
% netcp 
% netcp 
% netcp 
% netcp 
% netcp 


filel Y:filel 
Y:filel filel 
Z:filel Z:file2 
Xdex.c Ydex.c 
Y:subdir/filel filel 
filel file2 


copy ‘filel’ from the current directory to Y 

copy ‘filel’ from Y to the current directory 

cp command on remote machine 

copy from X to Y 

copy from a sub-directory 

an error— use the cp command 


f See the Unix Programmers Manual (Version 7 only). 
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2. Listing Requests in the Network Queue 

To see where your command is in the queue, type 

% netq 

A typical output of which looks like: 

From To Len Code Time Command 

X:your-name Y:remote-name 100 b99999 Mar 23 18:05 netcp filel Y:filel 

The format is similar to that of the Ipq command. The files are sent one at a time, in the order 
listed. If netq tells you the queue is empty, your request has been sent already. The queues for 
different destinations are totally separate. 

% netq Y 

will list just the queue destined for the Y machine. Netq summarizes requests from other users. 
The command 

% netq —a • 

will print the requests from all users. 


3. Removing Requests from the Network Queue 

If you want to cancel your net request, and “b99999” (see the netq example above) is 
your “Code,” use the command 

% netrm b99999 

which will remove the request (if it hasn’t already been sent). Furthermore, 

% netrm — 

will remove all your net requests in the queues on the local machine (you must have made the 
request in order to remove it). 


4. Sending Mail over the Network 

To send mail to remote machines, use the mail command with the remote account 
prefixed by the destination machine’s name and a “Y:schmidt”, for example, refers to an 
account “schmidt” on the Y machine. The full sequence is illustrated below: 

% mail Y:schmidt 

{your message to user “schmidt” } 

{control-d] 

This will send to user “schmidt” on the Y machine the text you type in. As with intra¬ 
machine mail, the message is terminated by a control-d. 

You do not need an account on a remote machine to send mail to a user there. 


5. Reading Mail over the Network 

It is also possible to read your mail on remote machines. From the X machine, the com¬ 
mand 

% netmail Y 

sends a command to the Y machine to take any mail you may have and mail it back to you. As 
a precaution, the mail on the remote machine (Y in this example) is appended to the file 
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“inbox”. Netmaii has —I, — p, — n and — f options just like netcp. If a machine is not 
specified, the default machinef is used. If the —q option is specified (like netcp) no message is 
sent back if there is no mail. 

Netmail also takes a —c option: 

% netmail — c Y:username 

which turns the command into a “mail check” command. A message is sent back telling the 
user whether the specified username has mail. No password is required. As above, the ~*q 
option suppresses the message if there is no mail. This command was designed to be put in C 
shell “.login” files. 


6. Using the Lineprinter over the Network 

Remote lineprinters can be used with the netlpr command: 

netlpr [—m machine ] I—c command file) file! ...filen 
v 

which sends the files its arguments represent to the lineprinter on machine. It will prompt you 
for an account and password. The —1, —p, —n and —f options may be supplied, as in the 
netcp command. If the —c option is specified, a different printing command (default is “lpr”) 
can be specified; see Appendix A for the list of printers allowed. Copies of the files are not 
made in the remote account. 


1 . Net Prototype Command 

The above commands all use internally one more general command—the net command 
which has the following form: 

net [—m machine] [—1 login] [—p password] [—r file] [—3 I—n] [—q] [—f] command 

Net sends the given command to a remote machine. The machine may be specified either with 
the —m option or in the “.netrc” file (for the specific names, see Appendix A). If not 
specified, a default is used. —1, —p, —n, —q and —f are as explained above for the netcp 
command. The —r option indicates the local file which will receive the output (the standard 
output and standard error files) of command when it is executed on the remote machine. By 
default this output is written ot mailed to you. Thus, for example, to find out who is on the Y 
machine when yor. are logged in on the X machine, execute the following command: 

% net —rn Y "who" 

which will run the who command on the Y machine; the response will be written or mailed to 
* you. Similarly, 

% net —m Y —r resp "who" 

will take the output (result) and return it to you in file ‘resp 1 on the local machine. If instead 
you want the result of the who command to remain on the Y machine the command 

% net —m Y "who >resp" 

will create a file ‘resp 1 in your login directory on the Y machine. It is a good idea to put the 
command in quotes, and it must be in quotes if I/O redirection (<, >, or other syntax special 
to the shell) is used. 

If you do not specify the remote machine explicitly (or in the “.netrc” file, explained 
below), the default machine will be used (see Appendix A). 

t (see “Setting Defaults” below) 
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The — option indicates that standard input from the local machine is to be supplied to the 
command executing remotely as standard input, thus if defaults for the login name and pass¬ 
word are set up correctly as described below, 

% net — m Y — "mail ripper" 

{ message to ripper } 

{control-d} * 

is equivalent to „ 

% mail Yiripper 

{ message to ripper ] 

(control-d] 

The net command also has other options not documented here. See the UNIX 
Programmer’s Manual sections for more details. \ 

Setting Defaults I 

Instead of repeatedly typing frequently-needed opt'ons for every invocation of the various 
network commands, the user may supply in his login directory a file “metre”, which contains 
the repeated information. The “metre” file is typically used to specify login names on remote 
machines, as well as other options. An example of such a file is given below: 

default Y 

machine Y, login dracula 

machine Z login dracula, quiet yes 

This example sets the default machine to Y so that for net commands where a remote machine 
is not explicitly specified, the command will then be executed on the Y machine. The second 
arid third lines indicate for the Y and Z machines a login name of “dracula” should be used to 
network commands, and to assume the “quiet” option on all commands destined for the Z 
machine. The complete list of options that may follow the machine indication is: 


Option 

metre options for each machine 

Parameter Default Comment 

login 

name 

localname 

login name for remote machine 

password 

password 

(none) 

password for remote login name 

command 

command 

(none) 

default command to be executed 

write 

yes/no 

yes 

if possible, write to user 

force 

yes/no 

no - 

always prompt for name and password 

quiet 

yes/no 

no 

like the — q option 


In setting up the “metre” file, if the “default” option is present, it must be the first line 
of the file. The information for each machine starts with the word “machine” and the machine 
name and continues one or more lines up to another machine indication (or the end of the 
file). Input is free-formal. Multiple spaces, tabs, newlines, and commas serve as separators 
between words. Double quotes (") must surround passwords with blanks or special characters 
in them. 

How to Specify Remote Passwords 

For the commands which require the password for the account on the remote machine, 
there are a number of ways to specify the password: 
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•© letting the command ask you, as in the netcp example in Section 1, 

21 specifying it with an alias (if using the C shell), 

3D putting it into the current environment if the local machine is running UNIX Version 7, 

4D specifying it on the command line with the —p option, 

5D storing it in the “.netrc” file, described in the previous section. ■ 

These can be ranked in order of security, from 1 = greatest security to 5 = lowest secu¬ 
rity, from the point of view of security of.passwords from unauthorized use by other users and 
possibly an illicit super-user. Each is described in turn: 

ID If you make no effort to specify the remote password elsewhere, the network commands 
will prompt you with: 

Password (mach:username): 

Type your password, followed by a carriage return. This is the most secure mode of 
specifying passwords. If the net command is executed in the background (i.e. with “&”) 
then the command can’t read the password from your terminal and one of options 2-5 
below must be used. 

2D The alias feature of the C shell can be used to specify the remote password. The com¬ 
mand 

% alias netcp netcp —I godzilla —p Spass 
in the “.cshrc” file, followed by 
% set path=you r-passwd 

right before using the network will set for subsequent netcp commands the login name 
“godzilla” and password “passwd”. This alias command must be given everytime you 
login (see the UNIX Programmers Manual section for the C shell (csh (1)) for more infor¬ 
mation about alias. Do not put this alias command in your “.login” file. 

3D If running on a Version 7 UNIX system, the password can be put in the current environ¬ 
ment. The command (to the C shell) 

% setenv MACHmc/j 'netlogin — m mch' . 

or (to the default Version 7 “Bourne” shell) 

% MACH mch= 'netlogin — m mch' 

% export MACHmch 

will prompt you for a login name and password for the remote machine mch and put an 
encrypted copy of the password in your environment. (Note the back-quotes to the 
shell.) Subsequent network commands will find it in your environment and not prompt 
you for it. These encrypted passwords are invalidated after the user logs out. Type “man 
netlogin” for more information on the netlogin command. 

4) Each net command takes a — p option on the command line to specify the password. 
These are usually put in shell command scripts. These shell script files should have file 
mode 0600 — use the chmod (I) command to set the mode. 

53 The remote password can be specified in the user’s “.netrc” file. If passwords are 
present, the “.netrc” file must have mode 0600 (as in #4 above). 

The system managers recommend options 1-3 and warn against 4 and 5. Should someone 
break into your account on one machine, and you use option 4 or 5, you will have to change 
your passwords on all net machines for which your passwords have been stored in shell script 
files or in the “.netrc” file. 
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Log File 

The file “/usr/spooi/berknet/logfile” has a record of the most recent requests and 
responses, each line of which is dated. Lines indicating “sent” show' the file name sent; lines 
indicating “rev” show commands executed on the local machine (C: ), their return code (R: ), 
and their originator. For example, on the Y machine, the loghle: 

Feb 28 10:29: rev X: neil (neil) R: 0 C: netep design Ytdesign 
Feb 28 10:43: sent tuck to Z (z00466, 136 bytes, wait 2 min 3 sec) 

Feb 28 11:05: rev X: bill (bill) -R: 0 C: netep structures Y:structures 

shows three entries. In this example, there are two netep commands sending files from the X 
machine to Y, each from a different user. The second command sent was originated here by 
“tuck” and is 136 bytes long; the command that was sent is not shown. The command 

% netlog 

will print the last few lines of this file. Its prototype is 
netlog —num 

where num is an integer will print the last num lines from the file. 
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Appendix A 

The Network at Berkeley 


i 

1. The Configuration (March 1, 1980) 



The Current State of the Berkeley UNIX Network 

Machine 

Internal 

Run 

Default 

Name 

Name 

By 

Machine 

A 

A 

Computer Center 

C 

B 

B 

Computer Center 

D 

C 

C 

Computer Center 

A 

D 

D 

Computer Center 

C 

E r 

E 

Computer Center 

C 

F 

F 

Computer Center 

E 

G 

G 

Computer Center 

E 

Ing70 

I 

INGRES Group 

IngVAX 

IngVAX 

J 

Ingres Group 

Ing70 

Image 

M 

Signal Processing 

ESVAX 

ESVAX 

0 

EE-CE Research 

CSV AX 

Q 

Q 

Computer Center 

E 

ArpaVax 

R 

Fabry’s Arpa Project 

CSVAX 

SRC 

S 

Survey Res. Cent. 

D 

MathStat 

T 

Math-Stat Dept. 

CSVAX 

CSV AX 

V 

CS Research 

Cory 

Onyx 

X 

CS Research 

ArpaVax 

Cory 

Y 

EECS Dept. 

CSVAX 

EECS40 

Z 

EECS Dept. 

ESVAX 


\ 
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If a path exists from the local machine to the requested remote machine, the network will for¬ 
ward the request to the correct machine. 'Thus Cory users may communicate with all the other 
machines on the network as well as C and CSV AX (with a degradation in speed because of the 
intermediate machine(s)). The links between Jng70—IngVAX, CSVAX—ArpaVAX, A—C, 
C—D, C-E, B-D, E-F, and E-G run at 9600 Baud, the other links run at 1200 Baud. 

2. Documentation 

The network commands (net, netq, netrm, netlog, netcp, netmail, netlpr, netlogin) are all 
documented in the UNIX Programmers Manual. For example, 

% man netq 

will print the netq manual section. 

There are two more documents available: 

Network System Manual 
Berkeley Network Retrospective 

The Manual is intended for the systems staff who will maintain the network. The Retrospective 
is my Master’s report and details the history of the project, discusses the design, and lists future 
plans. 

There is an up-to-date news file: 

% news net 
or 

% help net 
or 

°/o cat /usr/net/news (if those fail} 

which prints news about the network, dated and with the most recent news first. 

The UNIX Programmer’s Manual, section I, has information on the chmod, cp, mail, who, 
and write commands mentioned in the text. Also, the help command has information about file 
protections: 

% news access (on the Cory machine) 

or 

% help permissions (on the CC machines} 

3. Features at Berkeley 

a) There is a built-in character limit of 500,000 characters per single transmission, which 

cannot be overridden. Files larger than 200, 000 bytes will be queued for transmission 
between Midnight and 6AM. Longer files must be split into smaller ones in order to be 
sent. * 

b) The 1200 Baud links between machines seldom transmit any faster than 80 characters per 
second (for 9600 Baud links, 600 characters a second), and can slow to a fraction of that 
in peak system loading periods. This is due '.0 an expansion of the data packets to 
accomodate a seven-bit data path, wakeup time on the machines, and the packet sent in 
acknowledgement. Heavy file transfer is faster by magnetic tape. 

c) On the VAX systems the net commands are all in 7usr/ucb\ Your search path on these 
VAX’s should be set to include the directory ‘/usr/ucb’; otherwise you will have to prefix 
all net commands fay ‘/usr/ucb’, as in Vusr/ucb/netcp’. 

d) Limited Free Commands 

Users who do not have accounts on remote machines may still execute certain com¬ 
mands by giving a remote login name of “network”, and no remote password. The com¬ 
mands currently allowed are: • • 
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bpq 

netlog 

res 

vpq 

whom 

epq 

netq 

rcslog 

w 

write 

finger 

ps 

resq 

where 

yank 

Ipq 

pstat 

trq 

who 



The Ipr command is allowed on the INGRES machine. Also, mail to remote machines and 
netlpr between Computer Center machines do not require a remote account. The EECS40 
machine allows no free commands (but allows the sending of mail). 

For example, to execute an Ipq command on the A machine, the user would type: 

% net —1 network — m A “who 11 

e) If no machine name specification is in the front of a full path name, the first four charac¬ 
ters are checked and the machine is inferred from that if possible. In the command 

% netcp filel /ca/schmidt/filel 

the second file name is equivalent to “C:filel”, if you are “schmidt” on the C machine. 

f) The network can only send files in one direction at a time. Thus confirmations can slow 
down heavy file transfer. If you regularly use a shell script to transfer a set of files, the 
—q option to netcp will improve transfer time. 

g) The network creates a heavy load on the system and thus is expensive to run. If general 
user throughput is adversely affected, a charge will be implemented on the Computer 
Center machines. 

h) When transferring files, quota overflow will result in a partial copy, so you should check 

the-space requirements of the file being sent. >. - 

i) The Computer Center “A” machine’s phototypesetter is usable from other network 
machines. If on one of the B-E machines, you do not need an account on the A machine. 
You simply type 

% troff — Q other-options file(s) 

instead of the normal 

% troff other-options file(s) 

The troff command is executed on the local machine and the phototypesetter instructions 
are sent to the A machind. You will be sent mail both when the file is queued and when 
it is finally typeset. To see your place in the troff queue, type: 

% trq * 

on any Computer Center machine. There is a command ■ \ 

% trrm code 

(where code is the code from the trq command) to remove queue files before they have 
been typeset. Trrm must be executed on the same machine from which the job was sub¬ 
mitted. 

If you are on a non-Computer Center machine, you may use the nettroff command: 

% nettroff options file(s) * 

which is similar to the “troff —Q” command earlier. You will need an account on the A 
machine and the trrm command doesn’t work from a non-Computer Center machine. 

If using nettroff, no more than 15 pages may be sent to the typesetter. If using troff 
more than 15 pages may be sent only if the —s option is specified (see troff(l) for more 
information). The network will not transfer any file longer than 500,000 characters to the 
A machine. (It is best to aim for files of 25,000 characters or less)f. For more 

t Characters from troff s output, not the user’s source files* It is our general experience that troff outputs 
roughly twice as many characters as are in the source file (before any eqn or tbl preprocessing.) 
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information, type . 

man troff {on the Computer Center machines] 

or 

man nettroff {on the other machines] 

The nettroff command is not supported by the Computer Center; 

j) The netlpr command allows “epr”, “bpr", and “vpr” as alternate lineprinters (using the 
—c option). 

4. Bugs in systems at Berkeley (As of March 1, 1980) 

a) If you set the variable time in the C shell, extraneous time stamps may appear in response 
messages. The correct way to set the variable time in the C shell is 

if ($?prompt) then 
set time — num 

endif 

where num is the time interval in seconds. 

.tii 

b) The file mode should be preserved by netcp and it should be possible to default the second 
file name to a directory as in cp(I). 

c) Various response messages are lost. This includes “fetching” files when the file being 
retrieved never arrives. I suspect this has something to do with unreliable delivery of 
error messages, but this is not reliably reproducible. 

d) The network makes no provision for errors in transit on intermediate machines, such as 
“No more processes” or “File System Overflow”. While these occur only rarely, when 
they do, no message or notification is sent to anyone. 

eV The network commands are too slow on heavily-loaded instructional machines. The net 
command has to read the password file, “metre” file and the “/etc/utmp” file. 

f) The queue files are normally sent shortest-job first. Unfortunately, under heavy loading 
the queue-search becomes too expensive and the network will choose the next file to send 
from the first 35 queue entries it finds in the queue directory, so the user should not 
depend on the requests being sent shortest-first. 

g) Comments and bug discoveries are encouraged and can be sent by local or remote mail to 
“csvax:schmidt”. 
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Sep 23 13:37 1981 netmail Page 1 


From kev Tue Mar 31 21:26:40 1981 netmail from elec70 

Pete: X have just found out that cpio is MUCH worse than even X had feared! 
Forgetting for a moment its lack of a tape directory that means it must read 
the entire tape to find something, and forgetting that it goes at a speed 
approaching absolute zero, you have only to create a zeroKLength file 
called "TRAILER!!!" to completely stuff it. It uses this to indicate the end 
of the dump you see, and cannot differentiate between a normal cretin's file 
called this, and the real McCoy that it sticks on itself. Are these idiots 
allowed to breed over there? Does Bell double-up as the local mental asylum? 

kev 

From mhtsa!ianj Thu Jul 9 16:32:44 1981 remote from usa netmail from basser40 

this arrived for you 

I pass it on without comment 

you can respond via 

mhtsa! ihuxa! pur-ee!mike 

ian 

>From uucp Thu Jul 9 01:05:17 1981 

>From **RJE** Wed Jul 8 20:35:55 1981 remote from ihuxa. 

>From mike Wed Jul 8*14:19:36 1981 remote from pur—ee 
To: ihuxalmhtsalianj 

For Peter Ivanov 

To enable an 11/44 to work as a unibus terminator on the vax there 
are 2 things which must be done. 

1. Modify the m7094 board so that addresses from 64k to 128k appear 
to be in the I/O page. To do this, see the last page of the m7094 
prints. Insert a 74S05 in the spare socket location El24. Connect 
pin 1 of the 74S05 to pin 9 of the 74S373 at E93. Connect pin 2 of 
the 74S05 to pin 8 of the 74S22 at E83. Without these modifications 
the 11/44 cannot talk tc the VAX memory. 

2. You can only put 64lc of memory on the 11/44, as memory on the 11/44 
ties up UBA addressing space for the buffered data paths. To do this, 
take the 128kw memory which comes with the 11/44 and make it look like 
it has 64kw by inserting jumper W2 on the M8722 memory board. If you 
somehow managed to get. a 64kw (128kbyte) board from DEC you won't have 
to do this. 

Plug a unibus cable into the last slot in the 11/44 and connect 
to the UBA where the arbitrator normally resides (M9044 card). The 
11/44 can be halted and the vax unibus' will still work. 


From lindsay Tue Aug 18 09:44:32 1981 netmail from agsm 
Wanted: 

A part time programmer to convert a Fortran program, developed 
on an IBM 370 system, tc use f77. Initial work will be on AGSM's 11/70, 
but completion will be done on a VAX (with UNIX). The program concerned 
solves linear programming & integer programming problems. Estimated 
conversion time is about 2 weeks. 

Contact: Lindsay Harris, rm423 at AGSM - Ext 273. 
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From andrew Sun Aug 23 14:44:21 1981 remote from usa netraail from basser40 
DSW(l) UNIX Progr aimer's Manual DSW(l) 


NAME 

dsw - delete from switches 
SYNOPSIS 

(put number in console switches) 

dsw 

core 

description 

dsw reads the console switches to obtain a number n, prints 
the name of the n-th file in the current directory, and 
exits, leaving a core Image file named core. If this core 
file is executed, the file whose name was last printed is 
unlinked (see unlink(2)). 

The command is useful for deleting files whose names are 
difficult to type. 

SEE ALSO 

rm(l), unlinlc(2) 

BUGS 

This command was written in 2 minutes to delete a particular 
file that managed to get an 0200 bit in its name. It should 
work by printing the name of each file In a specified direc¬ 
tory and requesting a 'y' or "n" answer. Better, it should 
be an option of rm(l). 

The name is mnemonic, but likely to cause trouble in the 
future. 


Printed 8/11/81 PDP-7 local 1 


From kev Sun Sep 20 20:02:27 1981 
Subject: panic! 

You may be interested in a method proposed by richardg for forcing the 
vax to panic (and successfully tried by myself). The old odd-address-in-pc 
won't work of course, because the vax considers Instructions on an odd 
boundary a real challenge, and leaps in there with all boilers going. 

The method is to halt the cpu, deposit a non-existent virtual address in pc 
(such as 60000000) and continue it: 

H 

D PC 60000000 
C 

and whammo! one dead (but nicely panic'd) vax. 

* 

kev 

From kev Sat Sep 19 13:41:50 1981 netraail from elec70 
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Pete: some light reading: 

From 8037185 Mon Sep 14 13:22:49 1981. 

Subject: There is an unwanted file of mine named 'mastermind' sitting 

in the (' ,(is this root?), directory. X don't know how it got there, 
maybe some misshap while I was transfering it to another of my own 
directories, but I don't want it. I tried removing it but that didn't 
work. Can you refer me to some type of wizzard. 

/userl/6.641/6.641-1/8037185 

At this point X removed the file and mailed this chap for more information. 
His reply was: 

From 8037185 Tue Sep 15 09:18:03 1981 
Subject: About that file in /. 


It was originaly mailed to me by another user on the 70, (thus it was in mail) 
I wanted to transfer it to my directory '’stuff" direct from the mail file. 

I.think i typed "s stuff/mastermind", which did place the mastermind file in 
"stuff". 

That was last Friday. I didn't suspect that there was a duplicate file in 
/ until i spotted it while i was jumping around directories yesterday,(Monday) 

Although i could not remove the file, or change its name, i could edit it, 
so i reduceded it size from about 2000 to 2. 


Thats about it. 


My reply to his reply was: 
Subject: That file in / 


userl/6.641/6.641-1/8037185 
j.mitchell. 


Thank you for your assistance in this matter. Plainly it represents a gross 
breach of security that you were able to create a file in /, so we will now 
devote considerable energy to putting, an ice-pick through "mail”. Xn the 
meantime, we would appreciate it if you would remain silent on the matter. 

kev 

My opinion is that I am fed up to the back teeth with these half-hearted 
ALL-POWERFUL programs that are plainly written by incompetents and half-wits. 
I think Michael should spend next week looking very carefully at mail, 
and clean the rotten pile of worm-infestation up. I can understand now 
why other places leave mail non—blessed, and simply demand that you leave 
a writable-by-others mail file around. The point is, if it wasn't for all 
the useless bloody gimmicks, it COULD be done properly (as Steven Fraser 
proved under level 6). With a little bit of care and attention, and 
one-tenth of a brain, it should be possible again. 

PS: I won't even bother to voice an opinion on Mail. 

FPS: you can feel free to publish this! 

PPPS: no reply from hobk yet on his mail. * 

PPPPS: today, for example, I only had to remove one (1) root-owned mb ox, 
and one (1) root-owned .mail.lock. Wonderful! Things are really improving! 




EUROPEAN UNIX USER GROUP 
COMMITTEE 

Chairman ; Alan Mason, Heriot-Watt University 
Editor : Bruce Anderson, University of Essex 
Member (s) : Peter Collinson, University of Kent 


R.A.Mason 

Computer Engineering 
Heriot-Watt University 
Mountbatten Building 
31-35 Grassmarket 
Edinburgh EHl 2HT 
(Tel. 031-225-8432 x 155} 

12th June, 1981 


Peter Ivanov, 

Editor AUUGN, 

Dept, of Computer Science, 
P.O. Box 1, 

Kensington 2o33, 

Australia. 


Dear Peter, • 

I just received a copy of AUUOJ where you announced the 'UNIX V7-small machine 
distribution that I sent you. I felt that I should point out that this is not 
a 1 Heriot-Watt' product, but truly an EUUG product. Although a number of 
iB^i^iduals from my installation were involved (notably Jim McKie) , so were many 
from other sites. Heriot-Watt is simply now acting as a distribution centre for 
the package and for collecting fixes as they come in (23 pages now,- most of which 
are required in the original Bell version) . 


The people actually involved with the package were: 




Hugh Conner 

Alan Mason 

Jim McKie 

Zdravko-Podolski 

Colin Prosser 

Dave Rosenthal 
i 


Heriot-Watt University, Elect. Eng. 
Heriot-Watt University, Computer Eng., 
Edinburgh Regional Computing Centre. 

Glasgow University, Computing Science. 
Science Research Council, Computing. Division. 
Edinburgh University, Dept, of Architecture. 


and many have since carried on to develop it further. To be announced in the near 
future (July/August) is a second tape with lots of other goodies: 


Usdr & Kernel Overlays (i.e. F77 & Lint will work) 
Terminal Description Libraries 
Graphics Package 

. Npw & Reworked Utilities . . 

Contiguous File Handling 


Ongoing and planned for distribution next year is a system which is so removed 
from the original that we might call it V8, but more likely V7+. 
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The point I am making is that no one individual or site is responsible for 
these developments, and the credit (or otherwise) should be given to the Group 
as a whole. 

In all fairness, it is really ray fault for misleading you. I should never 
have had our site named on the packaging documents, but that was where I wanted 
the BUG reports to come. 


Yours 


R.A. 
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The EUUG have recently had an election for the period 1981-1982 and formed 
the committee: *• . . . . \ 


Chairman 
Secretary 
Treasurer 
Membership Officer 
Executive Editor 
Editors 

Member 


Alan Mason 
Peter Collinson 
Emrys Jones 
Hugh Connor . 

Jim McKie 
Bruce Anderson 
Cornelia Boldyreff 
Nigel Martin . 



Mike Banahan 


As yon will see from this list, we now have three editors! This is an attempt 
to push up the frequency of our newsletter. Two of these individuals (newsletter 
editor’s) are in point of fact responsible for the physical collation, printing, 
publishing and distribution of the newsletter. The first (executive editor) is 
responsible for the gathering of material and re-distribution to newsletter editors 
and the remaining committee. It is for this reason that I now write. Could you 
in future please send our exchange copies of your newsletters, meeting announcements, 
meeting reports etc to our Executive Editor: 

_ dTim McKie, • 

Executive Editor, EUUGN, . ; 

Unix Support Officer, 

Edinburgh Regional Computing Centre, 
c/o EdCAAD, . 

20 Chambers Street, ’ " . 

EDINBURGH, 

Scotland. 


I would further appreciate it if you could ensure that members of your committee 
and meeting/conference chairpersons/hosts are made aware of this policy change so 
that we can be assured that most publishable material is coming through the one 
channel. • 


As in the past I myself will continue to receive your software offerings and 
to’caxry out local re-distribution of them.'^o those of you that handle software 
distribution on a per-meeting basis, I woifld appreciate it if the meeting organisers 
could be kept informed of our exchange agreement. 
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As a final request, if any cf your members are intending European 
visits, I would suggest that they, make contact with me giving a short 
nofee of their interests. This done, I can suggest to them a number of 
sifees that they may wish to visit, and if the timing is right, invite 
them to attend local and/or European meetings. 



ccs USENIX 

USR/GROUP 

UNI-OPS 

AUUG 

CUUG 



Walter Zintz 7 Uni-Ops 

Post Office Box 5182, Walnut Creek, California 94596 USA 
260 Marshall Drive, Walnut Creek, California 94598 USA 
Telephone (415) 933 -8564 mornings 

Peter Ivanov / Computer Science 
Electrical Engineering 

University of New South Wales number: 300? - 

Post Office Box 1 
Kensington 2033, Australia 

date: 16 JUL 81 


I hope you have received at least 

the first issue of the Uni-Ops newsletter, Pipes & Filters, which has 
been airmailed to you long since. If not, let me introduce Uni-Ops as 
a users* .group for Unix and C in business and personal computing. 

The first major Uni-Ops project is 
to compile the first worldwide mailing list of Unix/C people of all 
sorts. This is intended to benefit both those who want to mail to such 
a list and those who want to receive information by mail on the latest 
products and services in the field. My compilation method is simply to 
proclaim that anyone who believes his name should be on this list should 
send Uni—Ops his name and address. I*m asking for a mention in your 
newsletter to spread the message in your part of the world. 

To help the chary reader make up his 
mind, Uni-Ops has adopted two firm policies. First, NO NAMES WILL BE 
GIVEN OUT, EVER. All mailers must ship their materials to Uni-Ops to 
be addressed and mailed, so even list users will never actually see. the 
list. Second, use of the list (to the extent provided above) will be 
open equally to everyone whose material concerns C or Unix. There will 
even be frequent co-op mailings for those who must hold their mailing 
costs to rock-bottom levels. For overseas mailers' benefit, I can supply 
contacts with local printers whose work I can vouch for. 

To simplify our clerical work, each 
organizafion, or department within a large organization, should send a 
single list of all its Unix/C personnel If possible—Organization name 
and mail address at the top of the sheet, followed by the names (and mail 
codes, if necessary) of the individuals at that address. Typewritten 
lists are preferred; print-out or hand-lettering must be effortlessly 
legible. All list contributions should be mailed to: 

Uni-Ops List 

Post Office Box 5182 

Walnut Greek, California 9^596 USA 

Inquiries regarding list rental, co-op mailings or local printers should 
be sent fo Ur.i-0ps List Manager at the same address. 
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Post Office Box 5182 
Walnut Creek, California 94596 USA 

(415) 933-8564 mornings 



Dear Computer Professional: 


Bell Labs' Unix® Software Tools, other equiv¬ 
alent operating systems: do you use them or sell them for 
commercial applications? Then let me tell you about Uni-Ops, 
the active new user/vendor group for people involved with 
Unitory operating systems on business's computers. 

Uni-Ops is people talking to people—in print 
and face to face—about the opportunities and obstacles that 
arise as the Unitory family becomes the first de facto uni¬ 
versal- operating system. Talking about Unitory itself, the 
hardware it runs on, the business programming that runs on 
it, C and the other languages used with it. Talking about 
technical matters, business aspects and personal involvement. 

Our primary communications channels are a monthly 
journal, a semi-annual directory of Unitory products, and 
national conferences starting this Pall—all described below. 

' ' Every member receives 12 issues a year of Pipes 

& Fillers, the Uni-Ops journal, featuring news of the Unitory 
field and the people in it, bulletins and reviews of new or 
revised products, articles (some technical, all practical), 
notes on Uni-Ops activities, and pithy letters from members. 
Classified ads are available under Software, Hardware, Employ¬ 
ment, Services and Education headings, at $7 for up to 100 
characters and spaces combined, 50 for each extra character 
or space, payment with order. Preprinted advertising mater— 

, ial can be mailed in the envelopes with Pipes & Filters for 
870 per 8^x11 page plus 835 per piece. The first issue of 
Pipes & Filters will be mailed to members on June 4th. All 
editorial and advertising material intended for that issue 
must r-each Uni-Ops not later than May 22nd. ... . .. ......... 
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The Uni-Ops Directory is a cataloging of all' 
known Unitory—based software that could be useful in commer¬ 
cial systems, whether offered-by -vendors or co-op groups. 

Data tables are arranged by software type and cross-indexed 
by supplier. There is no charge for being listed, and list¬ 
ing forms will be mailed June 11th to everyone who. has asked 
for them. Deadline for return of completed forms is July 
17th, because the first edition of the Directory will be sent 
to all members on August 6th. • 

- Face to face interaction comes at Uni-Ops first 

national meeting, being planned for the week beginning Octo¬ 
ber 11th, in San Francisco. (But not at a high-rise hotel 
in the downtown ratrace—our site is just beyond, in exqui¬ 
site Cow Hollow.) The technical and professional sessions-, 
will emphasize participation rather than chairwarming, and 1 
vendor activities are being structured to provide more 
information and less exhaustion for vendors and visitors 
alike. Careful simultaneous-activities programming should 
provide everyone with something of interest most of the time. 
Uni-Ops members will be the first to learn the specifics of 
our conferences, through Pipes & Filters, and are entitled 
to substantial reductions in registration fees. 

Of course we're already receiving requests for 
Uni—Ops involvement in other Unitory matters. Some of the 
more general topics of interest seem to be: 

standardization in Unitory and C • . 

renegotiation of license terms 

regional meetings and newsletters 

special-interest subgroups 

programmer training and certification .. 

promoting Unitory- to the outside world 

Uni-Ops will be active on these things, co-operating with 
Usenix and STUG- where logical, as member energy permits. 

Uni-Ops membership is open to any interested 
person at $24 per year; there are no corporate or institu¬ 
tional categories. If all this sounds like your kind of 
group, then welcome aboard! 

WaMn 

. - - “ ~v-~- Valter Zintz ..- - 

Executive Director 
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UNI-OPS MEMBERSHIP APPLICATION 


Please enrol 1 me as a charter member of Uni-Ops for one year, ending 
the 31 sh of May 1982. My dues payment of US$24.00 is enclosed. 


TOUR 

NAME 

AND 

COMPLETE 

MAILING 

ADDRESS 


If you wJ.ll jot down your specific Unitory-related interests on any or 
all of -fciie topics below, it will help Uni-Ops plan its activities. 


"Which cjhass of Unitory? ( )Bell Labs’ Unix ( )Software Tools ( )other 
Commercial Applications Areas __ 


Applications Languages _ 

Computer- 'Size/Type ____ 

Specific Computers or CPUs 


Peripherals___ 

Database Systems * _ ' __ 

Networking__ 

Graphics ___ 

Standardization_____ 

Licensiisgg ___ ■ • _____ 

Personnel._ ' _ • 

Market Bevel opraent 

Career Advancement_ 

other topics _ v """ ' ~ .• " _‘_____ 

UNI-OPS* Post Office Box 5182, Valnut Creek, California 94596 USA 
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Pet.er I Man ou 

Dept. of Computer Science 
University of NSW 
PCS 1 

Kensinston 

New South Wales 2033 
Austral is 


Dear fir. Ivanov? 

ThanKs for the reply to r/ questions about the U200 emulator. 
It solved my problem auicKer than I thousht. 

We are considerina here a few ideas about UNIX-based systems 
and.■ products. Since you are settins up the.software catsloaue? 
you probably are the best source of references to the relevant 
people. Three items are now on our “hot list" , 

1) Real-time UNIX for process control? fast data acquisition 
an d ,n urn bar crunch i n a ? etc. 

2) An ADA compiler / interpreter / whatever under UNIX (hops- 
•fully a portable one). 

3) A "C" compiler (or even an entire UNIX system) for a Data 
Generai coMPUtsr i lc iiP5c »« a ). 

If you happen to Know of anyone worKins cn such items? please 
let me Know. I also Wellcome any direct contact from readers of 
this letter. 




- i - 

EDER STR. 49a, P.O.B. 72, TELEX 46400 BXHA IL , for No. 8351. TEL. 04 - 24 60 33 
31 000 HAIFA, ISRAEL 



April 29, 1981 


Peter Ivanov 
Dept, of Comp. Sci. 

University of New South Wales 
P.O. box 1 . 

Kensington NSW 2033 


Dear Peter, 

Could you please enter my subscription to the Unix User Group 
Newsletter. I am including a copy of my license and the subscription 
fee. 

I am the guru for an 11/34 system running level 6 UNIX in the 
.School of Electrical Engineering at Sydney University. This system, 
which is known on the UNSW-SU network as ”mhd", is used primarily for 
numerical modeling of problems related to HagnetHydroDynainic( MHD) power 
generation. My "mail" address on the network is roy:mhd. 

I also maintain an 11/03 system which runs MINIUNIX and is normally 
linked to the 11/34 via a serial line. The 11/03 system is a 
transportable data acquisition system which includes a dual AED 6400 
f-^°PPy disc, a Matrox graphical display, and a High Common-mode Voltage 
measurement system of our own design. For experiments, the 11/03 is 
physically transported to our experimental site at White Bay Power 
Station and is returned at the end of the day. 


Yours truly. 

Roy R. Rankin 

School of Electrical Engineering 
University of Sydney 
Sydney, 2006 
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The University of Western Australia 


Faculty of Architecture 
Nedlands, Western Australia 6009 
Telegrams Uniwest Perth, Telex AA 92992 
Telephone ( 09 ) 3 80 25 8 2 

25th June 1981 


Mr. P. Ivanov, 

Department of Computer Science 
Electrical Engineering, 
University of New South Wales, 
P.0. Box 1, 

KENSINGTON N.S.W. 2030 


Dear Sir, 

I have been given your name as contact for the 
UNIX Users Group. I would be grateful if you could give 
me any information on the availability of UNIX for a PDP11/24 
system with 256 KB memory and dual RL02's. In particular 
I wish to discover any hardware requirements of UNIX version 
6 and/or 7. My main interest is to establish what are the 
size limits for a FORTRAN program, i.e., whether it is poss¬ 
ible to utilize memory outside a single 64K byte page from 
a single program. 

I look forward to your early reply. 

Yours faithfully. 


(DR.) G.G. ROY 
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A Summary of the UNIX Operating System' 

Din Mao-shun 

Research Institute of Computing Technique 
Chinese Academy of Sciences 

Introduction 

t 

UNIX is a general-purpose, interactive, time-sharing operating system 
developed by Bell Laboratories in the.U.S.A. The designers, K. Thompson and 
D.M. Ritchie, implemented the system in 1969-70. Initially UNIX was written in 
assembler language, but was rewritten in the C language in 1973. About 10,000 
lines of code (1,000 still in assembler) form the kernel of the system. 

A variety of editions of UNIX for different applications have been brought 
out with the kernel as the base for extensions. Because of the portability of 
the C language the UNIX system has been transferred to several machines. The 
UNIX system is now running on the PDP-11 series, Interdata 8/32, Honeywell 6000 
etc. 


The UNIX system has achieved great and unexpected success for its 
superiority over other systems. By the end of 1978 there were 1,000 UNIX 
systems all over the world. The time-sharing system software provided by UNIX 
is even more than the sum of the relevant software provided by all other 
systems, (direct translation - ed) 

Fig. 1. illustrates the levels of the file system in UNIX from 'root" to 
directory to file'. UNIX files consist of three categories: common files, 
directories and special files. 


who | grep tom | wc' is a pipe line used to find how many times the 
is logged-in to the system. The command 'grep' selects lines from 
of who' containing the name 'tom' and these lines are counted by 

3.4 Programming Using SHELL 

4.1 Process Contro l 

4.1.1 Data Structure 


pipe line: 
user 'tom' 
the output 
'wc'. 


4.4 Implementation of the SHELL 


The command Interpreter, or SHELL, Is waiting for user commands at most 
times. On receiving a command the SHELL analyses it and makes ready all the 





parameters suitable for the format of the primitive "execute", then executes the 
fork primitive. At this time father and son procedures go different ways: the 
new-built son-procedure Implements the "execute" primitive using the code and 
parameters provided by the father-procedure. 

Tiie kernel, although it is small and simple, only about 10,000 lines of 
code altogether, has no less ability to manage system resources than other 
systems. 

Many programs which are at system level in other systems are at the user 
level in UNIX, though they still are part of the system from a functional point 
of view. This is to the advantage of revising and extending functions of the 
system, as well as for portability of the system. 


The above was translated from an article I saw in the 'CSIRO DMS UNIX News 
Sheet about the spread of UNIX to China. The DMS people had not translated it 
so I asked one of our Chinese exchange staff to have a go. 

peteri 
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A very large loosely-coupled computer system( HITAC M-200H) 
at the University of Tokyo Computer Centre 


* 

1. The largest computer system in the world 

being shared by many universities 


Computing facilities -at the Computer Centre are being used on a 
shared basis by some 5,000 researchers at many universities mainly in 
Tokyo area. To fill these users' needs, the Computer Centre has 
installing what is believed to be the largest computer system in the 
world. The system is built around one of the fastest general-purpose 
processors HIT&C 14-200H and consists of the following components.- 

(1) 8 (J-1-20FH) processors and 64 megabytes (KB) of main storage' *[• 

(2) 6 IAP (Integrated Array Processors) for all but global 

processors. . j 

(3) B drums (each 15 MB, total 120 M3) for the TS5 system. Theie 
are about 60 terminals installed in the centre building. 

(4) 96 spindles of 300 MB discs and 32 spindles of 200 MB discs. 
Thus the total nominal disc capacity is about 36,880 MB. 

(5) Minimally configuraa HSS (Mass Storage System) with 706 magnetic 
tape cartridges (each 50 MB, total 35,000 MB) and 12 spindles of 200 
MB staging discs. 

(6) 5 data communications processors and 3 network processors for 
500 simultaneous terminal (TSS and remote-job entry) connections. 

(7) For batch processing, the following I/D equipments are provided. 
Most of these are used directly by users on do-it-yourself basis. The 
scheme is called "advanced open-batch processing". Many color CRT 
displays are deployed for this purpose. 

7 Card readers 

13 Line printers, each with an automatic paper 
cutter and some with paper-bo:-: feeders 

12 Magnetic tape transports 

1 ICanji laser-beam printer/plotter (720 lines/min, cut sheets) 

1 Floppy disc input/output 

6 XY plotters 

(8) Graphic displays . 

1 High-resolution display 

3 Storage-scope displays 

1 Color graphic display 

(9) Kanj i I/O .terminals 

5 Kanji display with alphanumeric/Kanji.keyboards 

3 Ink-j et Kanji printers . 


The features of the M200H( V0S3) system 

(1) Loosely-coupled multi-processor system 

All user files can be shared by all tightly-coupled 
systems ( each with 2 CPU + 16 1*3 storage) 
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;t within DG. AZ-Toxt. a word proces- 
1 system that runs under AOS and is 
d inhouse nl DG. is available lo 
pse OEMs, but few have taken advnn- 
} of it. Although few OEMs hold a high 
lion of AZ-Texl. DGcoritinues lo push 
product because it has spent millions 
dollars developing it, according to 
rces close to DG. 

source inside DG admitted there 
- battles going on between suppor- 
and detractors of AZ-Text, bul added: 
ires always controversy within cor- 
itions on any big issue." 


mhhiu, lumors naa ocen circulating in the from Ihe company. 
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lother proposed solution lo the word 
essing gap was Worcfcraft, reported- 
standalone word processor in an MPT 
inaf. But it is believed VVordcraft's 
e, if still alive within the company, is 
jing by a thread. 


CUPERTINO, California — ZBOOO- 
bosed multiuser development system 
designed to run under the Bell Labora¬ 
tories Unix operating system has been 
introduced by Zilog Inc. 

The Z-Lab 8000 programmer's develop- 




When Dr. Who said this to the aliens he had 
inadvertently told them the name of the only 
computer in the galaxy that is an incredible 
communicating system, understands all industry 
standard languages, has a fantastic range of 
software solutions and can increase its power 
in seconds. 

Prime Computer. 

OFFICE AUTOMATION SYSTEM 
Prime Computer’s Office Automation System 
is totally integrated, combining functions 
previously only available individually, like word 
processing, communications and data 
processing. A single work-station handles text 
manipulation and processing for clerical staff 
and communications and tracking functions for 
management, all with secured password- 
controlled access. All these features are available 
on the same system that also handles traditional 
data processing applications. 


“1 APPLICATION SOFTWARE 
_ -J Prime supplies and supports a wide range of’ 

1 applications software through a division called 
1 • “Pnme Solutions” The large virtual address 
■. : j space, processing power and complete 
-_v.S compatibility across the range m ake Prime the 
..: 1 Meal computer for software developers. This has 
; I led to a proliferation of available application 
’ 1 software packages running on Prime computers 

, (The aliens, incidentally, turned out to be just 
_ | some over-enthusiastic Prime buyers.) , 
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ment system can support up to 16 users 
and runs under the Zeus operating sys¬ 
tem, the vendor's enhanced version of the 
Unix system. 

It can be used to develop code for all 
Zilog MPUs and supports up to 1.5 
megabytes of error-correcting memory 
using 24 megabyte Sin Winchester disk 
drives. si 

The Z-Lab concept separates hard¬ 
ware and software development loots into 
specifically tailored devices that can 
operate alone, with each other or, with de¬ 
vices made by other manufacturers, thus 
protecting the user’s investment in both 
the hardware and software areas, a com¬ 
pany spokesman said. 

The large user base and software base 
of development-related applications in 
the Unix system offers advanced docu¬ 
mentation tools, the vendor said. 

The more than 60 utilities include pro¬ 
grams that teach the user about Zeus, 
send messages lo users, remind users of 
tasks to be completed and search files 
for a particular character pattern. 

The Z-Lab 8000 programmer's deve¬ 
lopment system is available in two ver¬ 
sions. Model 20, priced at SUS27.000, 
includes CPU board, two intelligent con¬ 
trollers. 25GK-bytes of ECC memory, one 
24 megabyte Winchester disk drive and a 
cartridge tape drive. Model 30, priced at 
5US33.950, offers 512K-bytes of ECC 
memory and two 24 megabyte Winchester 
drive>s. Both models feature miscella¬ 
neous storage compartments. . 

Zilog was represented in Australia bv 
Zap Systems Ply Ltd, St Leonards, NSW, 
which has been acquired by Hanimex. A 
new distributor for the development 
system has yet to be appointed. 



NEW YORK — In recent announce¬ 
ments, both Intel Corp and Hewlett- 
Packard Co unveiled details of tneir own 
32-bit microprocessor chips, with Intel 
ready now to market its first two-chip 
system. 

Using Ada as a programming lan¬ 
guage, Intel’s IAPX432 system is com¬ 
prised of three 64-pin chips containing 
a total of 200,000 transistors, a com¬ 
pany spokesman said. The system in¬ 
cludes two general data processors and 
an I/O processor that can link attached 
peripherals and memory circuits. 

The system, the result of a five-year, 
$US25 million research and development 
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